-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[CI] Fix the build on 3.0 #46
base: develop
Are you sure you want to change the base?
Conversation
Should get things passing on: - ruby-2.5.3 - jruby-9.1.17.0
…a supervision tree" See d9b806a
Makes it easier to ensure that the build stays green from the RSpec 2.99 -> RSpec 3.x transition.
This conversion is done by Transpec 3.4.0 with the following command: transpec -f * 65 conversions from: obj.should to: expect(obj).to * 51 conversions from: == expected to: eq(expected) * 8 conversions from: it { should ... } to: it { is_expected.to ... } * 6 conversions from: obj.should_not to: expect(obj).not_to * 5 conversions from: =~ /pattern/ to: match(/pattern/) * 5 conversions from: it { should_not ... } to: it { is_expected.not_to ... } * 3 conversions from: obj.should_receive(:message) to: expect(obj).to receive(:message) * 2 conversions from: be_false to: be_falsey * 2 conversions from: its(:attr) { } to: describe '#attr' do subject { super().attr }; it { } end * 1 conversion from: lambda { }.should to: expect { }.to * 1 conversion from: mock('something') to: double('something') * 1 conversion from: obj.stub(:message) to: allow(obj).to receive(:message) * 1 conversion from: pending to: skip For more details: https://github.com/yujinakayama/transpec#supported-conversions
...with a documented, supported argument matcher block to #receive. Unsupported in #with: rspec/rspec-mocks#377 (comment) Supported in #receive: https://github.com/rspec/rspec-mocks#arbitrary-handling
Convert specs to RSpec 3.8.2 syntax with Transpec This conversion is done by Transpec 3.4.0 with the following command: transpec -f * 2 conversions from: obj.stub(:message => value) to: allow(obj).to receive_messages(:message => value) For more details: https://github.com/yujinakayama/transpec#supported-conversions
This reverts commit a9d85a5.
@bklang @lpradovera @gfaza Can you review this for me? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, other than the question about Cucumber/Ruby 1.9.3
s.add_development_dependency %q<cucumber>, [">= 0"] | ||
s.add_development_dependency %q<bundler>, [">= 1.0"] | ||
s.add_development_dependency %q<rspec>, [">= 3.0"] | ||
s.add_development_dependency %q<cucumber>, ["< 3.0"] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It looks like this was done to make Ruby 1.9.3 happy, but we no longer need to support that ancient version. Should this restriction be lifted?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bklang I was thinking about that too (actually, I completed the cuke upgrade locally and confirmed it's a small effort).
Reason for possibly not doing it.. a handful of cucumber features fail unless we fully embrace cucumber >= 3.0n syntax. But since the syntax is not backwards compatible, it means that the same features will have to remain different on support/2.x
vs. develop
.
I'd lean towards having the two branches have a common denominator, unless it drags down develop
in some way.
But I can be swayed - I can update this branch to embrace cuke 3.0 if you like it. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Your answer makes sense to me. There's no urgency to upgrade cucumber, so let's leave it for now. As you say, we can do this work whenever we have a better reason to do it, and in the meantime we benefit from keeping backports simple. 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Meant to reply back earlier... ... thanks man.
Up-port the CI fixes from #45 for RubyAMI 2.4 to 3.0: